Neither a Perpetuum Mobile nor a Perfect Software: Sincerity in the Relationship between the Manufacturer and the Client with Respect to Software Defects

Certain mechanical shortcomings in engines cannot be ascribed to errors in design or defects in construction. They are due to the fact that it is impossible to design and construct engines in a way that completely eliminates friction between its parts. Friction causes wear and tear that is proportional to the amount of use. Likewise, when it comes to software one should not expect it to behave any differently. One must expect a set of errors in the software that cannot be attributed to faulty design or construction. A set of errors will materialize as a function of the equally unavoidable logical “friction” between, on the one hand the necessary but hardly specifiable complexity of software, and on the other hand the following two requirements: 1) The necessity to observe strict limits of the cost and time of development, and 2) The necessity to offer a maximum simplicity of operation. In other words, just as mechanical deficiencies will be proportional to the amount of use to which an engine endures, the user of a software application will experience informational flaws (bugs) that are proportional in number to the use that s/he makes of the product. Once this is shown, we argue that the proper way to approach these software defects is neither via innumerable rounds of trial and error in laboratories, nor with mathematical algorithms that try to demonstrate correctness to 100%. Instead, we believe that the right way would be –analogous to mechanical systems– to deliver the product to the user with a minimal standard of quality but with a certifiable plan of preventive and corrective maintenance. Such a plan would assure the user that any errors that emerge are looked upon in due time, and that the manufacturer will try to keep the downtime as short as possible. All this leads us 1) to discuss the concept of complexity up to the point where we can show that it is possible to contrast it quantitatively with the limitation of cost and time of development, as well as with operational simplicity; the purpose being to establish a clear distinction between defects which can be attributed to complexity, and those which cannot; 2) to show how the occurrence of defects due to complexity is a function of use of the software in the same way as defects due to wear and tear are a consequence of the use of the engine; 3) to show the viability of the concept of a minimum standard quality in software; 4) to sketch the model of preventive and corrective maintenance of defects due to complexity and use of software, analogous or at least as effective as the preventive and corrective model of maintenance of mechanical wear and tear; 5) identify successful experiences in the software industry which resemble the above mentioned model; or elements that may contribute to its implementation; and 6) to propose and promote a culture of information system maintenance which would make it foreseeable for the user, acceptable, and finally budgetable, in a similar manner as the maintenance of an automobile. All of these should bring about a sincere relationship between producer and client, and reduce the level of discord between them.